store: Persist postponed index creation as a once-only operation#6583
Merged
Conversation
incrypto32
reviewed
May 28, 2026
Member
incrypto32
left a comment
incrypto32
left a comment
There was a problem hiding this comment.
Should copying/graft also set postponed_indexes_created = true?
Otherwise copieddeployments can keep the flag false and later create_postponed_indexes may recreate indexes that was intentionally not carried over.
incrypto32
approved these changes
May 28, 2026
Member
incrypto32
left a comment
incrypto32
left a comment
There was a problem hiding this comment.
Looks good but left one question
Track postponed-index creation in a new `postponed_indexes_created` column on `subgraphs.deployment` so the decision survives restarts and external index cleanup. The runner already gates creation on proximity to chain head; this makes the gate persistent. Two problems with the prior behavior are fixed: 1. An external process removes unused indexes. Because every call used `CREATE INDEX CONCURRENTLY IF NOT EXISTS` and we re-entered `create_postponed_indexes` on every restart, manually-dropped indexes were recreated. The flag now short-circuits the call after the first successful creation. 2. `start_subgraph` called `create_postponed_indexes` eagerly on every restart, including immediately after a graft when the deployment is far below chain head. That call is removed; the runner-side path (already gated by `close_to_chain_head`) is now the only trigger. The migration sets the flag to TRUE for deployments where `synced_at IS NOT NULL`, since those already had their postponed indexes created under the old code path. Also removes the redundant `WritableStore::postponed_indexes_created` AtomicBool: the runner's in-memory guard already limits calls to at most one per restart, and the DB is now the single source of truth.
Collaborator
Author
Nice catch! I changed things so that copy/graft now sets the flag when it is done creating indexes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Track postponed-index creation in a new
postponed_indexes_createdcolumn onsubgraphs.deploymentso the decision survives restarts and external index cleanup. The runner already gates creation on proximity to chain head; this makes the gate persistent.Two problems with the prior behavior are fixed:
An external process removes unused indexes. Because every call used
CREATE INDEX CONCURRENTLY IF NOT EXISTSand we re-enteredcreate_postponed_indexeson every restart, manually-dropped indexes were recreated. The flag now short-circuits the call after the first successful creation.start_subgraphcalledcreate_postponed_indexeseagerly on every restart, including immediately after a graft when the deployment is far below chain head. That call is removed; the runner-side path (already gated byclose_to_chain_head) is now the only trigger.The migration sets the flag to TRUE for deployments where
synced_at IS NOT NULL, since those already had their postponed indexes created under the old code path.Also removes the redundant
WritableStore::postponed_indexes_createdAtomicBool: the runner's in-memory guard already limits calls to at most one per restart, and the DB is now the single source of truth.